FB - jak na casto se menici tabulky
Otázka od: Karel Rys
21. 10. 2004 8:04
Dobry den,
na FB jsem pro export zmen v zasobe pouzival tento postup:
- dve tabulky: Zasoba, ZasobaEx
1. pri exportu se odeslou rozdily mezi Zasoba a ZasobaEx
2. provede se DELETE FROM ZasobaEx
3. provede se INSERT INTO ZasobaEx SELECT * FROM Zasoba
Coz samozrejme nelze delat prilis casto, jinak vznikne spousta "smeti", o
kterem se tu diskutovalo
nedavno. Nyni by vsak zakaznik rad, aby se export castio delal.
Neznate nekdo elegantni reseni, jak nahradit kroky 2 a 3 necim, co nebude
vytvaret moc "smeti"?
Popr. co se tyce FB 1.5 - jak moc zdrzuje pri provozu, kdyz se necha zapnuty
automaticky sweep
napr. po 10000 transakcich? Zatim jsme hodelali "rucne" v noci a to bezel
kratce.
Diky,
Karel Rys
Odpovedá: Slavomir Skopalik
21. 10. 2004 8:50
> na FB jsem pro export zmen v zasobe pouzival tento postup:
>
> - dve tabulky: Zasoba, ZasobaEx
> 1. pri exportu se odeslou rozdily mezi Zasoba a ZasobaEx
> 2. provede se DELETE FROM ZasobaEx
> 3. provede se INSERT INTO ZasobaEx SELECT * FROM Zasoba
>
> Coz samozrejme nelze delat prilis casto, jinak vznikne
> spousta "smeti", o kterem se tu diskutovalo
> nedavno. Nyni by vsak zakaznik rad, aby se export castio delal.
Je otazkou kolik zaznamu je takto vytvareno a mazano.
Pokud je to v prijatelnych mezi, tak neni treba se tim zabyvat.
>
> Neznate nekdo elegantni reseni, jak nahradit kroky 2 a 3
> necim, co nebude vytvaret moc "smeti"?
>
> Popr. co se tyce FB 1.5 - jak moc zdrzuje pri provozu, kdyz
> se necha zapnuty automaticky sweep
> napr. po 10000 transakcich? Zatim jsme hodelali "rucne" v
> noci a to bezel kratce.
Me to pripada, ze by se na to hodilo view.
U vsech DB nechavam automaticky sweep.
Slavek
Odpovedá: BRCKO Peter
21. 10. 2004 10:57
> na FB jsem pro export zmen v zasobe pouzival tento postup:
>
> - dve tabulky: Zasoba, ZasobaEx
> 1. pri exportu se odeslou rozdily mezi Zasoba a ZasobaEx
> 2. provede se DELETE FROM ZasobaEx
> 3. provede se INSERT INTO ZasobaEx SELECT * FROM Zasoba
>
> Coz samozrejme nelze delat prilis casto, jinak vznikne
> spousta "smeti", o kterem se tu diskutovalo
> nedavno. Nyni by vsak zakaznik rad, aby se export castio delal.
> Neznate nekdo elegantni reseni, jak nahradit kroky 2 a 3
> necim, co nebude vytvaret moc "smeti"?
Napriek tomu, ze som prelistoval knihu od P.Cisara, tejto problematike som sa
velmi
nevenoval pozornost, no logicky mi pripada, ze DROP TABLE ZasobaEx by mal byt
v takomto pripade vhodnejsi ako DELETE FROM (bez ohladu na pocet zaznamov).
Alebo sa mylim?
Peter Brcko
Odpovedá: Pavel Cisar
21. 10. 2004 11:38
Haj hou!
On 21 Oct 2004 at 11:57, BRCKO Peter wrote:
> Napriek tomu, ze som prelistoval knihu od P.Cisara, tejto problematike som sa
velmi
> nevenoval pozornost, no logicky mi pripada, ze DROP TABLE ZasobaEx by mal byt
> v takomto pripade vhodnejsi ako DELETE FROM (bez ohladu na pocet zaznamov).
> Alebo sa mylim?
DROP TABLE velmi casto nelze pouzit kvuli zavislostem na dalsi
objekty databaze. Pokud si dobre vzpominam, tak v pozadavcich na nove
vlastnosti FB je i prikaz ve stylu EMPTY TABLE, ktery by rychle
odstranil vsechna data pri zachovani metadat tabulky.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Kalhous
21. 10. 2004 12:06
> - dve tabulky: Zasoba, ZasobaEx
> 1. pri exportu se odeslou rozdily mezi Zasoba a ZasobaEx
> 2. provede se DELETE FROM ZasobaEx
> 3. provede se INSERT INTO ZasobaEx SELECT * FROM Zasoba
> Neznate nekdo elegantni reseni, jak nahradit kroky 2 a 3 necim, co nebude
> vytvaret moc "smeti"?
Nebylo by i "databazovejsi" delat to v jedne tabulce? Zalezi samozrejme na
tom co je to "zmena" ale treba kdyz me zajima jen zmena hodnoty mnozstvi ve
sloupci MN od posledniho exportu tak si pridat sloupec MNEX
"exportovany
stav" do ktereho pri exportu ulozim hodnotu z MN, pri dalsim
exportu pak
select jen radku kde MN<>MNEX a nasledne UPDATE MNEX=MN WHERE MN<>MNEX.
To me jen tak napadlo.
Odpovedá: Pavel Cisar
21. 10. 2004 12:23
Haj hou!
On 21 Oct 2004 at 9:03, Karel Rys wrote:
> Dobry den,
>
> na FB jsem pro export zmen v zasobe pouzival tento postup:
>
> - dve tabulky: Zasoba, ZasobaEx
> 1. pri exportu se odeslou rozdily mezi Zasoba a ZasobaEx
> 2. provede se DELETE FROM ZasobaEx
> 3. provede se INSERT INTO ZasobaEx SELECT * FROM Zasoba
>
> Coz samozrejme nelze delat prilis casto, jinak vznikne spousta "smeti", o
kterem se tu diskutovalo
> nedavno. Nyni by vsak zakaznik rad, aby se export castio delal.
Ono ani tak nejde o vznik smeti (ktereho neni zas tak moc, protoze
verze radku pro zruseny zaznam je velmi mala), ale o jeho odstraneni.
Pokud se data odsouvaji z tabulky, ktera je velmi casto vyuzivana pro
dulezite operace, je vhodne hned po commitnuti vymazu vetsiho
mnozstvi dat provest SELECT COUNT(*) z dane tabulky (pokud s ni ovsem
nepracuje jina transakce v rezimu snapshot, pak to nema vyznam), aby
se co nejrychleji provedl garbage collection (neni nutne provadet
primo sweep).
Pokud je na tabulce vice indexu (dva a vice), pak je vhodne podobne
odsuny provadet v dobe, kdy s databazi nikdo nepracuje (nebo alespon
minimum lidi), aby bylo mozne provest jejich deaktivaci a opetovnou
aktivaci (nejrychlejsi zpusob jak je zbavit smeti), pripadne provest
sweep. Za plneho provozu je lepsi sweep nez deaktivace/aktivace
indexu.
Nicmene takoveto optimalizace maji vyznam pouze pokud:
1. Potrebujete predpoveditelnost chovani a garantovani minimalniho
vykonu. FB ma vestavene samoozdravujici mechanizmy, ale okamzik
jejich spusteni, dobu provozu a miru ovlivneni vykonu nelze
prepdpovedet.
2. Samoopravne mechanizmy prokazatelne neuvedou databazi do
pozadovaneho stavu v pozadovanem case.
Takze nejlepe je vyzkouset si odsun za bezneho provozu a zmerit zmeny
ve vykonu, a teprve pokud vam nebudou vyhovovat zacit spekulovat nad
moznymi optimalizacemi.
> Popr. co se tyce FB 1.5 - jak moc zdrzuje pri provozu, kdyz se necha zapnuty
automaticky sweep
> napr. po 10000 transakcich? Zatim jsme hodelali "rucne" v noci a to bezel
kratce.
Zalezi na aplikaci. Pokud nedojde k zablokovani OIT, pak k
automatickemu spusteni sweepu nemusi nikdy dojit. Rozhodne doporucuji
automaticky sweep nevypinat, protoze je dulezitou bezpecnostni
pojistkou. Je mozne zmenit jeho hodnotu, ale implicitnich 20000 je
pomerne optimalni nastaveni.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Karel Rys
21. 10. 2004 13:16
Pavel Cisar dne 21 Oct 2004 v 13:09:
> Ono ani tak nejde o vznik smeti (ktereho neni zas tak moc, protoze
> verze radku pro zruseny zaznam je velmi mala), ale o jeho odstraneni.
> Pokud se data odsouvaji z tabulky, ktera je velmi casto vyuzivana pro
> dulezite operace, je vhodne hned po commitnuti vymazu vetsiho mnozstvi
> dat provest SELECT COUNT(*) z dane tabulky (pokud s ni ovsem nepracuje
> jina transakce v rezimu snapshot, pak to nema vyznam), aby se co
> nejrychleji provedl garbage collection (neni nutne provadet primo
> sweep).
>
> Pokud je na tabulce vice indexu (dva a vice), pak je vhodne podobne
> odsuny provadet v dobe, kdy s databazi nikdo nepracuje (nebo alespon
> minimum lidi), aby bylo mozne provest jejich deaktivaci a opetovnou
> aktivaci (nejrychlejsi zpusob jak je zbavit smeti), pripadne provest
> sweep. Za plneho provozu je lepsi sweep nez deaktivace/aktivace
> indexu.
Ahoj,
diky moc za popis. Tabulka ma nasledujici strukturu:
CREATE TABLE ZasobaEx
(
ZboziDetPobocka dMalyKodOdkaz NOT NULL,
ZboziDetKod dKodOdkaz NOT NULL,
KdePobocka dMalyKodOdkaz NOT NULL,
KdeLokace dMalyKodOdkaz NOT NULL,
PartiePobocka dMalyKodOdkaz NOT NULL,
PartieKod dKodOdkaz NOT NULL,
Fyzicka dMnozstvi,
Rezervace dMnozstvi,
Objednavky dMnozstvi,
VyrobaProdejne dMnozstvi,
CONSTRAINT ZasobaEx_Klic PRIMARY KEY
(ZboziDetPobocka,ZboziDetKod,KdePobocka,KdeLokace,PartiePobocka,PartieKod),
CONSTRAINT ZasobaEx_ZboziDet FOREIGN KEY (ZboziDetPobocka,ZboziDetKod)
REFERENCES ZboziDet
(Pobocka,Kod),
CONSTRAINT ZasobaEx_Partie FOREIGN KEY (PartiePobocka,PartieKod) REFERENCES
Partie (Pobocka,Kod),
CONSTRAINT ZasobaEx_Lokace FOREIGN KEY (KdePobocka,KdeLokace) REFERENCES
Lokace (Pobocka,Kod)
);
Ovsem krome modulu, co ma na starosti exportovani, s ni nikdo jiny nepracuje -
uzivatele se divaji
do tabulky Zasoba, zatimco ZasobaEx vlastne zachycuje stav zasoby v okamziku,
kdy probehl posledni
export na pobocky.
Da se tedy spolehnout na to, ze kdyz exportni modul v jedne transakci typu
snapshot smaze vsechny
zaznamy v ZasobaEx, da tam zaznamy nove zkopirovanim ze Zasoba, commitne, pak
pusti druhou
transakci (asi uz jen read-commited) a tam udela SELECT count(*) FROM ZasobaEx,
dojde k odklizeni
starych verzi na tabulce ZasobaEx? Za predpokladu, ze neni otevrena zadna jina
transakce typu
snapshot vuci teto databazi?
Dalsi moznosti, kterou jsem zvazoval, by bylo z ZasobaEx smazat jen ty radky,
ktere se oproti
Zasoba lisi nebo jsou nadbytecne, a pak z tabulky Zasoba nevkladat vsechny, ale
jen ty, ktere v
ZasobaEx neexistuji, ale nevim, zda to jde nejak efektivne v jednom dotazu
udelat - to jeste
vyzkousim (neco jako INSERT INTO ZasobaEx SELECT * FROM Zasoba a WHERE NOT
EXIST (SELECT * FROM
ZasobaEx b on (b.ZboziDetPobocka=a.ZboziDetPobocka)and.....) ).
Diky,
Karel Rys
Odpovedá: Pavel Cisar
21. 10. 2004 15:50
Haj hou!
On 21 Oct 2004 at 13:45, Karel Rys wrote:
> Da se tedy spolehnout na to, ze kdyz exportni modul v jedne transakci
> typu snapshot smaze vsechny zaznamy v ZasobaEx, da tam zaznamy nove
> zkopirovanim ze Zasoba, commitne, pak pusti druhou transakci (asi uz
> jen read-commited) a tam udela SELECT count(*) FROM ZasobaEx, dojde k
> odklizeni starych verzi na tabulce ZasobaEx? Za predpokladu, ze neni
> otevrena zadna jina transakce typu snapshot vuci teto databazi?
Ano. Pokud to bude FB Classic, pak se zrusene zaznamy odstrani ihned
pri SELECT COUNT(*), u Super Serveru se pouze zaradi do seznamu pro
zruseni a zrusi se na pozadi.
S pozdravem
Pavel Cisar ( ICQ: 89017288)
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase
Odpovedá: Karel Rys
11. 11. 2004 18:31
Pavel Cisar dne 21 Oct 2004 v 13:09:
> > na FB jsem pro export zmen v zasobe pouzival tento postup:
> >
> > - dve tabulky: Zasoba, ZasobaEx
> > 1. pri exportu se odeslou rozdily mezi Zasoba a ZasobaEx
> > 2. provede se DELETE FROM ZasobaEx
> > 3. provede se INSERT INTO ZasobaEx SELECT * FROM Zasoba
> >
> > Coz samozrejme nelze delat prilis casto, jinak vznikne spousta
> > "smeti", o kterem se tu diskutovalo nedavno. Nyni by vsak zakaznik
> > rad, aby se export castio delal.
>
> Ono ani tak nejde o vznik smeti (ktereho neni zas tak moc, protoze
> verze radku pro zruseny zaznam je velmi mala), ale o jeho odstraneni.
> Pokud se data odsouvaji z tabulky, ktera je velmi casto vyuzivana pro
> dulezite operace, je vhodne hned po commitnuti vymazu vetsiho mnozstvi
> dat provest SELECT COUNT(*) z dane tabulky (pokud s ni ovsem nepracuje
> jina transakce v rezimu snapshot, pak to nema vyznam), aby se co
> nejrychleji provedl garbage collection (neni nutne provadet primo
> sweep).
Jen pro ostatni, pokud by to nekdy resili, bych rad potvrdil, ze uvedena metoda
skutecne funguje a
jiz zadne problemy se spoustou starych verzi nemame. Testovano zhruba 20 dni v
ostrem provozu.
Dekuju! :-D
Karel Rys